The development of modern software applications has become a complex challenge. This is because modern software applications are typically comprised of a multitude of distinct software components each performing a certain piece of functionality of the overall software application. Accordingly, all software components of a software application have to work together in a consistent manner to execute a pre-defined “process”, which is to be understood as a series of steps to be executed in a specific sequence in order to achieve an overall computing task.
Examples of such complex software applications include applications for controlling an assembly line e.g. for the manufacturing of vehicles, the controlling of the tasks to be performed by individual computing systems in a flight control system, or the calculation of vast amounts of data for scientific purposes, such as weather forecasts or complex simulations. Another example of such software applications are business applications. Business applications are focused on the automatic controlling and orchestrating of individual computing systems that perform a task of an enterprise (so-called “business process”). Although the overall task to be achieved may be a business-oriented task, it is noted that the technical implementation of the underlying software application is typically extremely complex, since it typically spans numerous software application components distributed among the enterprise's information technology infrastructure.
Such components of a (business) software application may comprise e.g. implementation components (home grown code, i.e. self-developed components) and/or third-party components (i.e. components that are obtained from a third-party, such as open source components, software libraries, or the like). Apparently, a typical complex software application is comprised of a variety of implementation components and third-party components, which have to be properly combined. Even more complexity is added by using e.g. Web services that are running in external environments such as the public cloud. In addition, all these components may come with different versions.
In such a complex development scenario, so-called “implementation governance” becomes a key factor to minimize both technical and legal risks. For example, when introducing third-party components into a software application under development, their licensing needs to be verified and the usage of chargeable third-party needs to be done in a controlled way to keep costs under control. Also so-called “security compliance” is an aspect relevant for third-party components as well as for self-developed components. Further, the development process itself needs to be governed, i.e. it must be controlled that the development process moves forward in a well-defined manner. For example, source code changes should only be committed to a central repository unless nightly builds and build verification tests are successful. In staged integration testing environments, certain tests have to be passed before components can enter the next stage.
To control the above-mentioned and other technical risks, the implementation of the software application needs to follow a pre-specified architecture, i.e. it has to be ensured that the (evolving) implementation of the software application only comprises specified components and specified dependencies between these components. Finally, also the lifecycle of the components needs to be governed, which also needs to cover the deprecation of components and their sun-setting. Yet another challenge is that the architecture of a (business) application typically evolves through the implementation, i.e. the architecture may change during the development of the software application. To ensure that the implementation does not violate any compliance rules, the governance thus needs to be carried out continuously, i.e. in a timely fashion, and needs to be flexible enough to cope with architectural changes.
Furthermore, complex software applications are typically developed and implemented by a huge number of software developers. In general, Integrated Development Environments (IDE) (http://en.wikipedia.org/wiki/Integrated_development_environment) are known that provide a framework of IDE tools for the development of software applications. A common IDE for the programming language Java is for example Eclipse. An IDE typically comprises besides basic IDE tools for build automation and debugging additionally a central source repository. The central IDE repository comprises the source code on which the software developers work. The source code is typically committed as implementation components in the source repository and deployed to the other developers. In the development of software applications and increasing complexity a huge number of developers work on the development of one common application and the source code thereof.
Those skilled in the art will appreciate that controlling the development of a complex software application is a difficult task, while severe technical problems can arise already if one single commitment of an implementation component in the source repository of a developer fails (e.g. a failure in build automation) and the incorrect source code is already deployed to the other developers, or even to the final product, before detection of the failure. This way, the source code of the entire software application might be affected by failures and consequently also the deployed software application built from the erroneous source code. For example, consider a software application of a process that operates an assembly line (as mentioned before) e.g. for the manufacturing of vehicles. An incorrect implementation of the software application could lead to a complete halt of the assembly line or even to damages to the produced vehicles.
“Service-oriented architecture (SOA) governance” (cf. e.g. http://en.wikipedia.org/wiki/SOA_governance) is an approach for controlling correct operations in a SOA, including among others ensuring that all SOA components interact properly in terms of communication patterns, security rules, response times and/or other performance characteristics (quality of services), ensuring that changing a service does not impose unforeseen consequences on service consumers (change management) and/or ensuring that services evolve within the system only in a controlled manner (lifecycle management). An exemplary application of general SOA governance with a SOA registry, namely “Governance Service Registry” and a “Process Engine” comprising a “Governance Approval Process” is disclosed in US patent application 2011/0314439 A1. Further lifecycle management is addressed in this document. Explicitly, a change of a lifecycle state of a software object is detected in the SOA registry. A “Governance Lifecycle” process for the object is implemented afterwards, in the SOA registry. This task of the implementation is achieved in transmitting an approval process input to the “Process Engine”. Further examples for the general use of registries and depositories can be found in the disclosures of US patent application no. 2009/0083268 A1 and U.S. Pat. No. 8,132,153 B2.
Contrary to SOA governance and the use of registries, US patent application no. 2010/0324952 A1 discloses an approach for continuously managing Governance, Risk and Compliance (GRC) within an integrated framework. The framework comprises an “Organization Inventory” and “Organization Risks” layer. The “Organization Inventory” layer comprises elements such as business components, system and applications and assets. Importantly, each asset in the “Organization Inventory” layer comprises a control with a respective linkage to a risk in the “Organization Risks” layer. A risk level is periodically measured based on a risk index, determined for each control in this disclosure. Further the GRC approach e.g. via the use of a GRC engine can be integrated into Cloud Computing (via integration layers) for improved governance efficiency (cf. related US Patent application no. 2012/0011077 A1).
However, while the above-discussed prior art approaches allow for continuous SOA governance, i.e. the controlling of the correct operation of an already developed SOA system, the proposed prior art systems lack a reliable and efficient way of controlling the development of software applications in the first place. In a further aspect, the known approaches do not address the problems of integrating a vast variety of different development tools into an overall development process, controlling that the individual components of the software application are properly integrated in a timely fashion (“continuous integration”), and controlling that the individual components of the software application conform to a pre-defined software architecture (“architecture governance”).
It is therefore the technical problem underlying certain example embodiments to provide an approach for controlling the developing implementation of a complex software application in a continuous way and to ensure that the software application conforms to a pre-defined architecture, so that failures in the developing application are recognized in early stages, thereby at least partly overcoming the above explained disadvantages of the prior art. In a further aspect, certain example embodiments aim at providing an approach to easily integrate a wide variety of existing development tools, so that these tools consistently work together in the overall development of a software application.
This problem is according to one aspect solved by a system for controlling the development of a software application. In the embodiment of claim 1, the system comprises:                a. an event channel, adapted for receiving at least one event that indicates an action performed by one of a plurality of existing development tools used in the development of the software application;        b. a policy-based event engine, adapted for evaluating the at least one event and for initiating at least one action of one of the plurality of development tools in accordance with at least one policy; and        c. a repository, adapted for storing at least one artifact to define an architecture of the software application, wherein the at least one artifact corresponds to a component of the software application and/or to a dependency between a first component and a second component of the software application.        
Accordingly, the embodiment defines a comprehensive control system for enabling a proper, reliable, timely and architecture-conformant control over the development of software applications. As mentioned before, nowadays complex software applications (such as business applications) are implemented by a plurality of software developers which typically use a vast variety of different development tools for the individual tasks of the overall development process. The software architecture shows similar complexity and is defined by software/implementation components that are related to each other via dependencies. The implementation components and dependencies therebetween have to be controlled in a continuous way for the early detection of policy violations, such as violations of the specified architecture.
Importantly, certain example embodiments propose an event-driven system comprising an event bus and a policy-based event engine exercising centralized control over the development of software applications. Explicitly, all activities that are triggered by the development tools are observed in the event channel and fed into the policy-based event engine. As one important advantage over the prior art, the event-driven approach allows for the addressed timely detection of anything going on in the development tools, comprising the detection of failures or policy violations in the very beginning. Furthermore, the policy-based event engine of certain example embodiments is not only capable of analyzing events triggered by the development tools, but also capable of triggering certain actions of the same or a different development tool in response, which results in a comprehensive control of the existing development tool chain. Certain example embodiments further provide an easy integration of any type of existing development tool, since the tool simply has to be “hooked” into the event bus.
The above-described system further comprises a repository which is adapted for storing at least one artifact to define an architecture of the software application, wherein the at least one artifact corresponds to a component of the software application and/or to a dependency between a first component and a second component of the software application. Accordingly, providing a repository in which the desired architecture of the software application to be developed is defined allows for a reliable evaluation whether the actual implementation of said software application (as it is performed by means of the development tools) actually conforms to the desired architecture.
In the following a plurality of scenarios related to failures in the development of software applications are briefly addressed to provide explicit examples and to underline the importance of the above-mentioned advantages.
Considering two components of a software application with an invalid dependency, it has to be ensured that this dependency is detected early on to avoid an inclusion or commitment of this incorrect dependency on the source code level. Besides software architecture, developmental processes, such as build automation, code repository management and automated deployment have to be considered in software applications. Considering further the build automation, e.g. the source repository should be closed whenever there is a build problem. Hence the commitment and deployment of an undesired or error-prone component or dependency can be prevented.
The development of the implementation is controlled automatically and continuously with the policy-based event engine of certain example embodiments to avoid the addressed failures and to allow for early detection of problems. This policy-based event engine is importantly adapted for evaluating at least one event in accordance with at least one policy, and further adapted for initiating at least one action of the development tool referenced by the event.
For example, the policy-based event engine might relate to the control of the detection of a new software component. The event (“Detection”) received via the event channel is evaluated in the policy-based event engine. One exemplary policy for such evaluation (“architecture compliance check”, i.e. “is the component conformant with the architecture”) is related to the verification whether the software component is in accordance with the software architecture defined by the repository's artifacts. Depending on the result of the evaluation of the policy, an appropriate action may be triggered. For example, the new component is approved if its conformance with the architecture is confirmed. In the other case, i.e. if it is evaluated that the new component does not conform to the architecture, the new component is rejected and certain actions are triggered to assure that the violation can be fixed (e.g. the source repository relating to the component in question can be closed, or an alert message, such as an email, can be sent to a developer who is in charge of the component).
In a further aspect, the policy-based event engine is further adapted for initiating at least one action of the development tool indicated by the event and/or one of the plurality of development tools which is different from the development tool indicated by the event. Accordingly, certain example embodiments allow not only to trigger a certain action of the particular development tool which issued an event itself, but also additionally or alternatively to trigger another one of the various development tools. In particular according to the latter aspect, the present system is thus capable of controlling the entire development tool chain involved in an arbitrarily complex development process.
For example, the plurality of development tools may be selected from the group comprising a build script, a test script, a binary repository and/or a source code repository, and the at least one action may be selected from the group comprising a test procedure, a build process, a deployment process, closing a binary repository and/or closing a source code repository. Accordingly, development tools may include IDE tools, providing various aspects of software application development (such as software architecture and/or build automation). The execution of a development tool results in an according action. In general it is plausible that not just the development tool referenced by the event is executed, but other tools as well. Typically software components run through a “lifecycle” with distinct developmental stages. Considering the example of new implementation components, mentioned further above, in a first stage a new integration component is detected and the IDE tool (build script) with the action (build process) is triggered. This action might cause the creation of a new software component and deployment in the source code after successful build. The implementation component enters the approved stage.
As already indicated above, the at least one component of the software application may be selected from the group comprising an implementation component (i.e. a self-developed component, such as “home grown” code) and/or a third-party component (i.e. a component obtained from a third party, such as open source components, binary components, software libraries, or the like).
In yet one further aspect, the at least one event reflects that a new component and/or dependency was added to the software application, and wherein the policy-based event engine is adapted for determining whether the repository comprises an artifact that corresponds to the new component and/or dependency. Accordingly, it can be easily checked whether a component, which was newly added to the software application by one of the development tools, was actually planned, i.e. whether it conforms to the architecture of the application. If it was planned, the repository already comprises a corresponding artifact.
In one further aspect, if it is determined that the repository does not comprise an artifact that corresponds to the new component and/or dependency, the policy-based event engine is adapted for creating a new respective artifact and for initiating an approval workflow. Accordingly, if no corresponding artifact is present in the repository for the newly added component or dependency, the addition of the component or dependency does not have to be forbidden altogether, but an approval process can be started in order to determine whether the newly added component or dependency should be kept in the software application.
In one further aspect, if the approval workflow results in the new artifact being rejected, the policy-based event engine is adapted for initiating an action of an existing development tool to remove the corresponding component and/or dependency. Accordingly, if it turns out that the newly added component/dependency did not pass the approval workflow, certain example embodiments reliably ensure that the undesired component/dependency is, preferably immediately, removed from the software application. This way, it is ensured that the software application stays free of erroneous aspects in a timely fashion.
In one further aspect, the at least one event reflects that a third-party component was added to the software application, and wherein the policy-based event engine is adapted for determining, by means of the at least one policy, whether the third-party component is compliant with the at least one policy. This includes e.g. the evaluation whether the third-party component is properly licensed or whether the third-party component introduces a security vulnerability. Accordingly, it can be efficiently and reliably controlled that only proper code is integrated into the software application to be developed at any time. Also, new policies can be added to the system of certain example embodiments to dynamically to cope e.g. with new acceptance tests, etc. for third-party products.
As it is apparent from the above, the repository of certain example embodiments provides a further central system component of the policy-based event engine comprising artifacts that define the intended architecture of the software application. An artifact may represent different types of components and/or their dependencies. For example, jar files, Java packages or Java sources and/or third party jars and/or third party products can be considered as types. Further, artifacts can have different lifecycle states. Artifacts typically comprise information such as a name and/or type to uniquely identify a component in the repository.
In yet another aspect, the system further comprises at least one event generator for a corresponding existing development tool, wherein the at least one event generator is adapted for creating the at least one event and for sending the at least one event to the event channel when the corresponding existing development tool performs an action. Accordingly, the system of certain example embodiments can be extended with at least one event generator, integrated as an interface between the at least one development tool and the governance event channel. The event generators are responsible for the generation of events and/or sending events to the governance event channel, thereby allowing an easy and reliable integration of existing development tools into the system of certain example embodiments.
In one aspect, the at least one event generator provides a function that is callable by the corresponding development tool to create the at least one event. Accordingly, the event generator might offer a so-called API (application programming interface) into which the corresponding development tool can hook itself in order to be integrated into the overall control system.
Additionally or alternatively, the at least one event generator is adapted for scanning a state of the corresponding development tool to create the at least one event. Accordingly, in this aspect the development tool is passively integrated into the overall control system without having to be adapted at all.
In another aspect, the at least one event is an XML-based event, which allows for a particularly easy and flexible definition of the contents of the events communicated within the system of the present invention.
Certain example embodiments are also directed to a method for controlling the development of a software application using any of the above-disclosed systems.
Furthermore, certain example embodiments also provide a computer program comprising instructions for implementing the above-described method.